ถ้าพูดถึงการพัฒนาซอฟต์แวร์ จะว่าไปแล้วมันก็ดูเป็นสิ่งนึงที่ติดลูป วนไปวนมาในชีวิตชาวเดฟเหมือนกันนะ โดยเฉพาะอย่างยิ่งกับองค์กรที่ใช้ Agile และ Scrum ในการทำงาน ที่มีการแบ่งการทำงานเป็นรอบ ๆ (Sprints)
.
เพราะคุณจะต้องเก็บ Requirements ของลูกค้าหรือผู้ใช้งาน แล้วก็นำไป Design และ Process เป็นซอฟต์แวร์ขึ้นมา จากนั้นก็ไปเก็บ Feedback จากลูกค้าหรือผู้ใช้งาน เพื่อนำ Feedback ไปปรับปรุงและพัฒนาซอฟต์แวร์ต่อในรอบถัดไป 🤔
.
👉 ซึ่งในการพัฒนาซอฟต์แวร์จะมีคำอยู่คำนึงที่มักพูดถึงกันบ่อย ๆ นั่นก็คือคำว่า “Technical Debt” หรือแปลเป็นไทยตรง ๆ ว่า “หนี้ทางเทคนิค” นั่นเอง
.
.
🔥 Technical Debt คืออะไร?
.
คำว่า Technical Debt เกิดขึ้นครั้งแรกโดย Ward Cunningham ตอนกำลังทำ Software ด้านการเงินอยู่ (เขาคือ 1 ใน 17 คนที่ได้คิดคำว่า Agile ขึ้นมา) ซึ่งเขาอยากอธิบายปัญหาที่เจออยู่ให้นายจ้างที่ไม่รู้เรื่อง Technical จึงเลือกเปรียบเทียบปัญหาทางเทคนิคกับหนี้ทางการเงิน (Monetary Debt) 💸
.
👉 คำว่า Technical Debt จึงพูดถึงปัญหาต่าง ๆ ด้านเทคนิค 💻 ไม่ว่าจะมาจากการเขียนโค้ดที่ไม่ดี Design ที่ไม่มีคุณภาพหรือไม่ยืดหยุ่น การละเลยปัญหาบางอย่างระหว่างพัฒนา หรือสาเหตุใด ๆ ก็ตามที่สุดท้ายก็ต้องมาตามแก้ทีหลังอยู่ดี
.
.
🔥 Technical Debt เกิดจากอะไรได้บ้าง?
.
เป็นคำถามที่มีคำตอบได้ล้านแปดอย่าง เพราะการพัฒนาซอฟต์แวร์คงหลีกเลี่ยงปัญหาไม่ได้อยู่แล้ว ยิ่งเป็นซอฟต์แวร์ขนาดใหญ่แล้ว ยิ่งใช้เวลามากเท่าไหร่ หรือมีคนร่วมพัฒนาเยอะแค่ไหน ก็อาจทำให้มีปัญหาอีกมากมายที่รอให้เราไปตามแก้อยู่ 🤕
.
👉 และที่สำคัญ Technical Debt ไม่ได้มีแค่ “โค้ด” เท่านั้น ไม่ว่าจะปัญหาจากการออกแบบ การเทสต์ การทำเอกสาร เครื่องมือที่เลือกใช้ในการพัฒนา หรือผู้ร่วมพัฒนาเองก็เป็น Technical Debt ได้เหมือนกัน
.
.
🔥 ตัวอย่าง Technical Debt ที่คุณอาจจะได้เจอ
.
🔹 ใช้ Architecture หรือ Tools ต่าง ๆ ไม่เหมาะกับสิ่งที่พัฒนาอยู่
🔹 รู้ว่าซอฟต์แวร์มีปัญหาตรงไหน แต่ไว้ก่อนจนสุดท้ายไม่ได้แก้
🔹 เวลาที่ให้ไม่สอดคล้องกับจำนวนงานที่ต้องทำ
🔹 ไม่เข้าใจซอฟต์แวร์ที่กำลังทำอยู่
🔹 ลืมทำ Documents หรือทำแบบขอไปที ไม่มีคุณภาพ
🔹 เขียนโค้ดซับซ้อน อ่านทำความเข้าใจและ Maintain ได้ยาก
🔹 คนในทีมมีภาระหนักเกินไป เช่น ทำงานมากกว่า 1 งาน ในเวลาพร้อม ๆ กัน
.
.
🔥 ทำยังไงดี ถ้าไม่อยากมี Technical Debt
.
เอาเข้าจริง ๆ แล้วการพัฒนาซอฟต์แวร์ คงจะหลีกเลี่ยง Technical Debt ได้ยาก แถมพอมีแล้วก็ต้องตามแก้กันอีก ราวกับส่งดอกให้เจ้าหนี้ 😔 แต่ถึงจะเลี่ยงได้ยาก ก็ไม่ได้แปลว่าจะเลี่ยงไม่ได้เลย เรามาดูวิธีลด Technical Debt กันดีกว่า
.
👉 แน่นอนว่า สิ่งที่ช่วยลด Technical Debt ได้ดีที่สุด ก็คือการไม่สร้างมันขึ้นตั้งแต่แรกด้วยวิธีต่าง ๆ เช่น เขียนโค้ดให้ Clean, ใช้ Test-Driven Development (TDD) ในการพัฒนา, ทำ Unit Testing รวมถึงวางแผนการพัฒนาซอฟต์แวร์ให้ดีและเลือกใช้เทคโนโลยีที่เหมาะกับสิ่งที่ทำ
.
🤔 แต่ถ้ามันเกิดขึ้นมาแล้ว จะทำยังไงล่ะ? ข้อแรกเลยคือต้องรู้ก่อนว่า อะไรเป็น Technical Debt ของซอฟต์แวร์ แล้วจึงหาวิธีแก้ไขปรับปรุง โดยจัดลำดับความสำคัญของปัญหาที่เจอ แล้วแก้ไปเรื่อย ๆ เพื่อให้ Technical Debt ลดลง อย่าแค่รู้ว่ามีปัญหาอะไร แล้วก็ไว้ก่อน จนสุดท้ายก็ไม่ได้แก้
.
.
📌 สรุปแล้ว Technical Debt ก็ไม่ได้ต่างจากหนี้ทางการเงินเท่าไหร่ เพราะมีหนี้ก็ต้องมีจ่าย และไม่ได้จ่ายแค่เงินต้น เราต้องเสียดอกเบี้ย และจะเสียมากขึ้นไปอีก ถ้าปล่อยให้หนี้ก้อนนี้อยู่ไปนาน ๆ เหมือนกับ Dev ที่ต้องมาตามแก้ปัญหาต่าง ๆ แถมถ้าทิ้งไว้นานแล้ว หรือเป็นหนี้ก้อนใหญ่ ก็ต้องใช้ทั้งแรง ทั้งเวลา และทั้งเงินในการขจัดปัญหานั้นมากกว่าเดิม
.
เพราะฉะนั้น ถึงเวลาแล้วล่ะ 🙌 ที่จะบอกลา (หรือลด) คำพูดก่อหนี้อย่าง “เดี๋ยวค่อยทำ” หรือ “ทำ ๆ ให้เสร็จไปก่อน” หรือ “ไม่ต้องมี Test หรอก” เพื่อให้เกิดหนี้ทางเทคนิคอย่าง Technical Debt น้อยที่สุดนั่นเอง~
.
.
🔖 ขอบคุณข้อมูลจาก
https://siamchamnankit.co.th/ว่าด้วยเรื่อง-หนี้ทางเทคนิค-technical-debt-ทำไมต้องใส่ใจ-b7a0c296b590
.
borntoDev - 🦖 สร้างการเรียนรู้ที่ดีสำหรับสายไอทีในทุกวัน
#TechnicalDebt #BorntoDevวันละคำ #BorntoDev
Search